Multi-homing internet service provider switchover system

ABSTRACT

A multi-homing Internet service provider switchover system includes a plurality of Internet service provider systems and a respective router device coupled to each Internet service provider system. Each router device is configured to determine that a route to its respective Internet service provider system is unavailable and, in response, advertise as a non-default router device with router lifetime information and lifetime information for an address of its respective Internet service provider system set to zero. A client device receives a router advertisement from a first router device that was selected as a default router device, and determines that it includes lifetime information for an address of its first Internet service provider system set to zero. In response, the client device selects a second router device as the default router device such that traffic is switched from the first router device to the second router device.

BACKGROUND

The present disclosure relates generally to information handlingsystems, and more particularly to an Internet service providerswitchover system for multi-homed information handling systems.

As the value and use of information continues to increase, individualsand businesses seek additional ways to process and store information.One option available to users is information handling systems. Aninformation handling system generally processes, compiles, stores,and/or communicates information or data for business, personal, or otherpurposes thereby allowing users to take advantage of the value of theinformation. Because technology and information handling needs andrequirements vary between different users or applications, informationhandling systems may also vary regarding what information is handled,how the information is handled, how much information is processed,stored, or communicated, and how quickly and efficiently the informationmay be processed, stored, or communicated. The variations in informationhandling systems allow for information handling systems to be general orconfigured for a specific user or specific use such as financialtransaction processing, airline reservations, enterprise data storage,or global communications. In addition, information handling systems mayinclude a variety of hardware and software components that may beconfigured to process, store, and communicate information and mayinclude one or more computer systems, data storage systems, andnetworking systems.

In many situations, information handling systems such as, for example,client devices, may be connected to more than one computer network in aconfiguration that is referred to as “multi-homing”. Such configurationsmay be provided in order to, for example, increase the reliability of anInternet Protocol (IP) network when client devices are served by morethan one Internet service provider. For example, in networked systemsthat communicate using the Internet Protocol version 6 (IPv6), clientdevices may select and use a default router device from a plurality ofrouter devices in order to communicate through the Internet using one ormore remote systems. The selection of the default router device from theplurality of router devices is made in response to router advertisementsfrom the plurality of router devices. However, when a link between adefault router device (i.e., that is currently selected as a defaultrouter device by a client device) and an Internet service provider goesdown, the use of IPv6 communications can result in lost traffic. Forexample, in many situations, the client device will not be able toswitch existing traffic from its currently selected default routerdevice (that can no longer communicate with its Internet serviceprovider due to the down link) to other router device(s) connected toInternet service provider(s) that are available.

Such issues typically result from IPv6 router advertisement standardsthat cause the default router device (which is connected to the Internetservice provider by the down link) to continue to send routeradvertisements that declare itself as the default router device, alongwith the address prefix for Internet service provider. As such, theclient devices connected to that default router device continue torefresh their default router lifetime information and Internet serviceprovider address lifetime information that may be provided by theInternet service provider. Conventional solutions to these issues thatutilize neighbor detection do not operate to detect the unavailableInternet service provider issue because the default router devicelink-local address will still be reachable by the client devices. Assuch, traffic continues to be sent by the client devices to the defaultrouter device, and ends up being dropped due to the down link betweenthe default router device and the Internet service provider.

Accordingly, it would be desirable to provide a multi-homing Internetservice provider switchover system.

SUMMARY

According to one embodiment, an information handling system (IHS)includes a communication system that is configured to couple to aplurality of router devices that are each coupled to a respectiveInternet service provider system; a processing system that is coupled tothe communication system; and a memory system that is coupled to theprocessing system and that includes instructions that, when executed bythe processing system, cause the processing system to provide a defaultrouter determination engine that is configured to: send, through thecommunication system, traffic to a first Internet service providersystem through to a first router device of the plurality of routerdevices that is selected as a default router device; and receive,through the communication system from the first router device inresponse to the first Internet service provider system becomingunavailable to the first router device, a second router advertisementthat includes router lifetime information and lifetime informationassociated with an address of the first Internet service provider systemset to zero and, in response, select a second router device of theplurality of router devices that is different than the first routerdevice as the default router device such that the traffic is sent to asecond Internet service provider system through the second routerdevice.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic view illustrating an embodiment of an informationhandling system.

FIG. 2 is a schematic view illustrating an embodiment of a multi-homingInternet service provider switchover system.

FIG. 3 is a schematic view illustrating an embodiment of a router deviceused on the multi-homing Internet service provider switchover system ofFIG. 2.

FIG. 4 is a schematic view illustrating an embodiment of a client deviceused on the multi-homing Internet service provider switchover system ofFIG. 2.

FIG. 5A is a flow chart illustrating an embodiment of a portion of amethod for Internet service provider switchover in a multi-homingsystem.

FIG. 5B is a flow chart illustrating an embodiment of a portion of amethod for Internet service provider switchover in a multi-homing system

FIG. 6 is a communication diagram illustrating first routeradvertisements in the multi-homing Internet service provider switchoversystem of FIG. 2 during the method of FIG. 5.

FIG. 7 is a communication diagram illustrating traffic via first trafficpaths in the multi-homing Internet service provider switchover system ofFIG. 2 during the method of FIG. 5.

FIG. 8 is a communication diagram illustrating a down link in themulti-homing Internet service provider switchover system of FIG. 2during the method of FIG. 5 that results in second routeradvertisements.

FIG. 9 is a schematic view illustrating an embodiment of a routeradvertisement used in the communications of FIG. 8.

FIG. 10 is a communication diagram illustrating address confirmationrequest messages in the multi-homing Internet service providerswitchover system of FIG. 2 during the method of FIG. 5.

FIG. 11 is a schematic view illustrating an embodiment of an addressconfirmation request message used in the communications of FIG. 10.

FIG. 12 is a communication diagram illustrating address confirmationreply messages in the multi-homing Internet service provider switchoversystem of FIG. 2 during the method of FIG. 5.

FIG. 13 is a schematic view illustrating an embodiment of an addressconfirmation reply message used in the communications of FIG. 12.

FIG. 14 is a communication diagram illustrating traffic via secondtraffic paths in the multi-homing Internet service provider switchoversystem of FIG. 2 during the method of FIG. 5.

DETAILED DESCRIPTION

For purposes of this disclosure, an information handling system mayinclude any instrumentality or aggregate of instrumentalities operableto compute, calculate, determine, classify, process, transmit, receive,retrieve, originate, switch, store, display, communicate, manifest,detect, record, reproduce, handle, or utilize any form of information,intelligence, or data for business, scientific, control, or otherpurposes. For example, an information handling system may be a personalcomputer (e.g., desktop or laptop), tablet computer, mobile device(e.g., personal digital assistant (PDA) or smart phone), server (e.g.,blade server or rack server), a network storage device, or any othersuitable device and may vary in size, shape, performance, functionality,and price. The information handling system may include random accessmemory (RAM), one or more processing resources such as a centralprocessing unit (CPU) or hardware or software control logic, ROM, and/orother types of nonvolatile memory. Additional components of theinformation handling system may include one or more disk drives, one ormore network ports for communicating with external devices as well asvarious input and output (I/O) devices, such as a keyboard, a mouse,touchscreen and/or a video display. The information handling system mayalso include one or more buses operable to transmit communicationsbetween the various hardware components.

In one embodiment, IHS 100, FIG. 1, includes a processor 102, which isconnected to a bus 104. Bus 104 serves as a connection between processor102 and other components of IHS 100. An input device 106 is coupled toprocessor 102 to provide input to processor 102. Examples of inputdevices may include keyboards, touchscreens, pointing devices such asmouses, trackballs, and trackpads, and/or a variety of other inputdevices known in the art. Programs and data are stored on a mass storagedevice 108, which is coupled to processor 102. Examples of mass storagedevices may include hard discs, optical disks, magneto-optical discs,solid-state storage devices, and/or a variety other mass storage devicesknown in the art. IHS 100 further includes a display 110, which iscoupled to processor 102 by a video controller 112. A system memory 114is coupled to processor 102 to provide the processor with fast storageto facilitate execution of computer programs by processor 102. Examplesof system memory may include random access memory (RAM) devices such asdynamic RAM (DRAM), synchronous DRAM (SDRAM), solid state memorydevices, and/or a variety of other memory devices known in the art. Inan embodiment, a chassis 116 houses some or all of the components of IHS100. It should be understood that other buses and intermediate circuitscan be deployed between the components described above and processor 102to facilitate interconnection between the components and the processor102.

Referring now to FIG. 2, an embodiment of a multi-homing Internetservice provider (ISP) switchover system 200 is illustrated. In theillustrated embodiment, the multi-homing ISP switchover system 200includes a plurality of Internet Service Provider systems 202 a and 202b that are coupled to a network 204 such as, for example, the Internet.Either or both of the ISP systems 202 a and 202 b may be the IHS 100discussed above with reference to FIG. 1 and/or may include some or allof the components of the IHS 100. While only two ISP systems 202 a and202 b are illustrated, any number of ISP systems are envisioned asfalling within the scope of the present disclosure. A plurality ofremote systems 205 a and 205 b are also coupled to the network 204, andmay be any systems reachable by the client devices discussed belowthrough the network 204. For example, either or both of the remotesystems 205 a and 205 b may be the IHS 100 discussed above withreference to FIG. 1 and/or may include some or all of the components ofthe IHS 100. While only two remote systems 205 a and 205 b areillustrated, any number of remote systems are envisioned as fallingwithin the scope of the present disclosure. The ISP systems 202 a and202 b are each coupled to a respective router device 206 a and 206 b.Either or both of the router devices 206 a and 206 b may be the IHS 100discussed above with reference to FIG. 1 and/or may include some or allof the components of the IHS 100. In specific embodiments, the routerdevices 206 a and 206 b are exit router devices positioned at theedge/exit of a network. In an embodiment, the ISP systems 202 a and 202b, the router devices 206 a and 206 b, and the network 204 may includehigh-speed, highly redundant forwarding services that move trafficbetween different layers in a networked system to provide variousnetwork services to users that are connected to the networked system, aswell as including other subsystems to provide other functionality knownthe art.

The multi-homing ISP switchover system 200 also includes a plurality ofswitch devices 208 a and 208 b (which each are directly coupled to eachof the router devices 206 a and 206 b) that each may be the IHS 100discussed above with reference to FIG. 1 and/or may include some or allof the components of the IHS 100. In an embodiment, the switch devices208 a and 208 b may provide for routing, filtering, and quality ofservice policies, as well as including other subsystems to provide otherfunctionality known the art. The multi-homing ISP switchover system 200also includes a plurality of access switch devices 210 a, 210 b, and 210c (which each are directly coupled to each of the switch devices 208 aand 208 b) that each may be the IHS 100 discussed above with referenceto FIG. 1 and/or may include some or all of the components of the IHS100. A client device 210 a is coupled to the access switch device 210 a,a client device 212 b is coupled to the access switch device 210 b, aclient device 212 c is coupled to the access switch device 210 c, andeach of the client devices 210 a-c may be the IHS 100 discussed abovewith reference to FIG. 1 and/or may include some or all of thecomponents of the IHS 100. As is known in the art, the access switchdevices 210 a-c and the client devices 210 a-c may include end stationsand servers accessing services in the networked system, as well asincluding other subsystems to provide other functionality known the art.In the illustrated embodiment, the router devices 206 a and 206 b, theswitch devices 208 a and 208 b, the access switch devices 210 a, 210 b,and 210 b, and the client devices 210 a, 212 b, and 212 c, are providedin a datacenter 214. While a specific embodiment of the multi-homing ISPswitchover system 200 system 200 is illustrated and described herein(e.g., the specific components in the datacenter coupled to the ISPsystems 202 a and 202 b), one of skill in the art in possession of thepresent disclosure will recognize that the teachings provided herein maybe beneficial to a variety of other switchover system 200 systems knownin the art. As such, different devices and systems may be utilized inplace of those illustrated and provided in different configurationswhile remaining within the scope of the present disclosure.

Referring now to FIG. 3, an embodiment of a router device 300 isillustrated. In an embodiment, the router device 300 may be either orboth of the router devices 206 a and 206 b discussed above withreference to FIG. 2. As such, the router device 300 may be the IHS 100discussed above with reference to FIG. 1 and/or may include some or allof the components of the IHS 100. The router device 300 includes achassis 302 that houses the components of the router device 300, onlysome of which are illustrated for clarity. One of skill in the art inpossession of the present disclosure will recognize that the routerdevice 300 may include a variety of router device components thatprovide for conventional router device functionality while remainingwithin the scope of the present disclosure. In the illustratedembodiment, the chassis 302 houses a processing system (not illustrated,but which may include the processor 102 discussed above with referenceto FIG. 1) and a memory system (not illustrated, but which may includethe system memory 114 discussed above with reference to FIG. 1) thatincludes instruction that, when executed by the processing system, causethe processing system to provide a router advertisement engine 304 thatis configured to perform the functions of the router advertisementengines and router devices discussed below.

The chassis 302 may also house a storage system (not illustrated, butwhich may include the storage device 108 discussed above with referenceto FIG. 1) that includes one or more router device databases 306 thatare coupled to the router advertisement engine 304 (e.g., via a couplingbetween the processing system and the storage system). The router devicedatabase(s) 306 may include one or more data structures that may be usedby the router advertisement engine 304 to route data traffic from theclient devices to the ISP systems discussed above, provide routeradvertisements as discussed below, and/or perform any of the otherfunctionality detailed below. While illustrated as housed in the chassis302, the router device database(s) 306 may be external to the chassis302 and coupled to the router advertisement engine 304 via a network orother connection while remaining within the scope of the presentdisclosure. The router advertisement engine 304 is also coupled to acommunication system 308 (e.g., via a coupling between the processingsystem and the communication system 308) that is housed in the chassis302 and that may include a Network Interface Controller (NIC), awireless communication device, and/or other communication componentsknown in the art that enable the router device 300 to be coupled toInternet Service Provider systems (e.g., the Internet Service Providersystems 202 a and 202 b in FIG. 2), switch devices (e.g., the switchdevices 208 a and 208 b in FIG. 2), and/or other network componentsknown in the art. While a specific router device 300 has beenillustrated, one of skill in the art in possession of the presentdisclosure will recognize that other router devices and/or networkingequipment may benefit from the teachings of the present disclosure, andthus the application of those teachings to such systems will fall withinthe scope of the present disclosure.

Referring now to FIG. 4, an embodiment of a client device 400 isillustrated. In an embodiment, the client device 400 may be any or allof the client devices 210 a, 212 b, and 212 c discussed above withreference to FIG. 2. As such, the client device 400 may be the IHS 100discussed above with reference to FIG. 1 and/or may include some or allof the components of the IHS 100. The client device 400 includes achassis 402 that houses the components of the client device 400, onlysome of which are illustrated for clarity. One of skill in the art inpossession of the present disclosure will recognize that the clientdevice 400 may include a variety of client device components thatprovide for conventional client device functionality while remainingwithin the scope of the present disclosure. In the illustratedembodiment, the chassis 402 houses a processing system (not illustrated,but which may include the processor 102 discussed above with referenceto FIG. 1) and a memory system (not illustrated, but which may includethe system memory 114 discussed above with reference to FIG. 1) thatincludes instruction that, when executed by the processing system, causethe processing system to provide a default router determination engine404 that is configured to perform the functions of the default routerdetermination engines and client devices discussed below.

The chassis 402 may also house a storage system (not illustrated, butwhich may include the storage device 108 discussed above with referenceto FIG. 1) that includes one or more client device databases 406 thatare coupled to the default router determination engine 404 (e.g., via acoupling between the processing system and the storage system). Therouter device database(s) 406 may include one or more data structuresthat may be used by the default router determination engine 404 to sendand receive traffic, make default router determinations, and/or performany of the other functionality discussed below. While illustrated ashoused in the chassis 402, the client device database(s) 406 may beexternal to the chassis 402 and coupled to the default routerdetermination engine 404 via a network or other connection whileremaining within the scope of the present disclosure. The default routerdetermination engine 404 is also coupled to a communication system 408(e.g., via a coupling between the processing system and thecommunication system 408) that is housed in the chassis 302 and that mayinclude a Network Interface Controller (NIC), a wireless communicationdevice, and/or other communication components known in the art thatenable the client device 400 to be coupled to access switch device(e.g., the access switch devices 210 a-c in FIG. 2) and/or other networkcomponents known in the art. While a specific client device 400 has beenillustrated, one of skill in the art in possession of the presentdisclosure will recognize that other client devices and/or computingequipment may benefit from the teachings of the present disclosure, andthus the application of those teachings to such systems will fall withinthe scope of the present disclosure.

Referring now to FIGS. 5A and 5B, an embodiment of a method 500 for ISPswitchover in a multi-homing system is illustrated. As discussed above,in some multi-homing systems such as, for example, IPv6 multi-homingsystems, conventional client devices may select default router devicesthrough which to send traffic to ISP systems in response to receivedconventional router advertisements, and when the link(s) between thedefault router device and the ISP system become unavailable, the clientdevices may not be able to switch traffic to other router device(s) thathave available link. This is due to IPv6 router advertisement standardsthat cause the default router device (which is connected to the Internetservice provider by the unavailable link) to continue to send routeradvertisements that declare itself as the default router device (alongwith the address prefix for Internet service provider), which causes theclient devices to continue to refresh their default router lifetimeinformation and Internet service provider address lifetime information.The systems and methods of the present disclosure operate to remedythese situations (which result in dropped traffic) by having the defaultrouter device detect the unavailable link to its ISP system, send out arouter advertisement with router lifetime information associated withthe default router device and lifetime information associated with theaddress of that ISP system set to zero, and have the client devicesselect a new default router device through which to send traffic to anavailable ISP system via an available link, as well as remove addressinformation associated with the unavailable ISP system such that trafficis sent to the available ISP system. Furthermore, systems and methodsare provided to ensure that client devices without security subsystemsenabled may perform such switchovers while ensuring that the switchoveris not in response to malicious router advertisements.

In the specific embodiments discussed below, such benefits are enabledvia a new router advertisement prefix option that is defined as a“remaining lifetime” and provided in addition to the conventional validlifetime and preferred lifetime that are provided in the prefix optionsof conventional router advertisements, as well as new Neighbor DiscoveryProtocol (NDP) messages that are defined as an “address confirmationrequest message” and an “address confirmation reply message”. Asdiscussed below, client devices may be configured to respond to a routeradvertisement that includes a router lifetime set to zero, a remaininglifetime set to zero, and/or an address (or address prefix) of an ISPsystem, by either immediately selecting a new router device as itsdefault router device and/or removing the address of the unavailable ISPsystem from its valid address list if it has security enabled, orsending an address confirmation request message, selecting a new routerdevice as its default router device, and/or removing the address of theunavailable ISP system from its valid address list if an addressconfirmation reply message is not received in some time period if itdoes not have security enabled. In the example provided below,communications between the router device 206 a and two of the clientdevices 210 a and 212 b in the embodiment of the multi-homing ISPswitchover system 200 of FIG. 2 are illustrated and described. However,one of skill in the art in possession of the present disclosure willrecognize that any number of router devices and client devices maycommunicate in the manner described below while remaining within thescope of the present disclosure.

The method 500 begins at block 502 where a client device receives routeradvertisement(s) from a router device(s) that advertise the routerdevice(s) as a default router device(s). Referring now to FIG. 6, anembodiment of the router device 206 a sending a first routeradvertisement 600 to each of the client devices 210 a and 212 b isillustrated, and one of skill in the art in possession of the presentdisclosure will recognize that the first router advertisement 600 may besent to any other client devices (e.g., the client device 212 cillustrated in FIG. 2) included in the datacenter 214. In an embodiment,the ISP system 202 a may advertise a default route (e.g., [::/0] or anyspecific route (e.g., [x::/y]) using a variety of dynamic routingprotocols known in the art, and upon receiving that default route orspecific route, the router advertisement engine 304 in the client device400 may then advertise itself as a default router device subject to thereceived route being present or active in router device database(s) 306(e.g., in a routing table). As discussed below, the client devices 210 aand 212 b (and any other client device in the datacenter 214) mayreceive router advertisements from any of the router devices in thedatacenter 214 and select one of those router devices as a defaultrouter device using router device selection methods (e.g., round robin)when an ISP is available through that router device. In the specificexamples discussed below, the router device 206 a is selected by theclient devices 210 a and 212 b in response to receiving the first routeradvertisement 600.

In an embodiment, the router advertisement engine 304 in the routerdevice 206 a/300 may utilize information in the router devicedatabase(s) 306 to send the first router advertisement 600 through thecommunication system 308 and to the client devices 210 a and 212 b thatmay include conventional router advertisement information such as, forexample, a router lifetime, a preferred lifetime, and a valid lifetimethat are valid and set to some non-zero time period (e.g., 2 hours orsome other time period defined by a network administrator or selected bydefault), as well as a link local address of the router device 206 a(e.g., fe80::acb2:12ff:fece:fe11 in the illustrated embodiment) as thesource address, an ISP prefix for the ISP system 202 a (e.g., 200::/64in the illustrated embodiment), and/or other router advertisementinformation known in the art, in order to advertise itself as a defaultrouter device. As would be understood by one of skill in the art inpossession of the present disclosure, in FIG. 6 the router device 206 b(e.g., a “second router device”) may send out router advertisements thatinclude conventional router advertisement information as well, such as,for example, a router lifetime, a preferred lifetime, and a validlifetime that are valid and set to some non-zero time period (e.g., 2hours or some other time period defined by a network administrator orselected by default), as well as a link local address of the routerdevice 206 b (e.g., fe80::acb2:12ff:fece:aa22 in the illustratedembodiment) as the source address, an ISP prefix for the ISP system 202b (e.g., 300::/64 in the illustrated embodiment), and/or other routeradvertisement information known in the art, in order to advertise itselfas a default router device.

The method 500 then proceeds to block 504 where the client deviceselects the first router device as a default router device and sendstraffic to a first ISP system through the first router device. Referringnow to FIG. 7, the default router determination engine 404 in the clientdevices 210 a/400 and 212 b/400 may receive the first routeradvertisement 600 from the router device 206 a and, in response, mayselect the router device 206 a as a default router device through whichto send traffic to the network 204 via the ISP system 202 a. Theselection of the router device 206 a as the default router device may bebased upon a round robin protocol and/or any other default router deviceselection criteria known in the art. Following the selection of therouter device 206 a as their default router device, each of the clientdevices may send and receive respective traffic 700 and 702 to and fromthe ISP system 202 a through the router device 206 a (e.g., via theaccess switch devices and switch devices discussed above with referenceto FIG. 2, and using information about the traffic being sent as well asany information stored in the client device database 406).

The method 500 then proceeds to block 506 where the client devicereceives a second router advertisement from the first router device thatincludes router lifetime information associated with the default routerdevice set to zero, and lifetime information associated with an addressof the first ISP system set to zero. In an embodiment, the routerdevices 202 a and 202 b may be configured to advertise themselves asdefault router devices by setting their router lifetime to some non-zeronumber, as well as advertise themselves as non-default routers bysetting their router lifetime to zero. In addition, the router devices202 a and 202 b may be configured to advertise themselves as defaultrouter devices only when a specific route (e.g., x::/y as defined by anetwork administrator) is present or active, and advertise itself as anon-default router when that specific route is not present or inactive.For example, the router device 206 a may be configured to advertiseitself as a default router device when a route to the prefix for the ISPsystem 202 a (e.g., 200::/64 in the illustrated embodiment, or defaultroutes (::/0)) is available, and advertise itself as a non-defaultrouter when the route to the prefix for the ISP system 202 a is notavailable. Similarly, the router device 206 b may be configured toadvertise itself as a default router when a route to the prefix for theISP system 202 a (e.g., 300::/64 in the illustrated embodiment) isavailable, and advertise itself as a non-default router when the routeto the prefix for the ISP system 202 b is not available.

Referring now to FIG. 8, an embodiment is illustrated of an unavailablelink 800 between the router device 206 a and the ISP system 202 a. Inthe illustrated embodiment, the link(s) between the router device 206 amay “go down”, be subject to a reduced bandwidth that greatly limits theamount of traffic that may be sent by the router device 206 a to the ISPsystem 202 a, and/or may otherwise become unavailable such that the ISPsystem 202 a is not reachable (or cannot receive a minimum amount oftraffic that client devices are providing to the router device 206 a forforwarding through the network 204) by the router device 206 a. However,in other embodiments, rather than an unavailable link, the ISP system202 a itself may become unavailable for any of a variety of reasons thatwould be apparent to one of skill in the art in possession of thepresent disclosure. In an embodiment, at block 506, the routeradvertisement engine 304 in the router device 206 a/300 may detect theunavailable link 800 using information in the router device database(s)306. For example, when a link between a router device and ISP systemgoes down, the router advertisement engine 304 in the router device 206a/300 may determine that it has not received a dynamic routing updatefrom the ISP system 202 a within some time period and, in response,remove or mark as inactive the route and, in response, with the defaultrouter functionality of the router device 206 a as well as the addressassociated with the prefix for that ISP system (e.g., 200::/64 in theillustrated embodiment) from the router device database(s) 306, and theprefix for that ISP system may be stored in the router devicedatabase(s) 306 as an invalid prefix.

In response to detecting the unavailable link 800, the routeradvertisement engine 304 in the router device 206 a/300 may utilizeinformation in the router device database(s) 306 to send second routeradvertisements 802 a and 802 b through the communication system 308 andto the client devices 210 a and 212 b. The second router advertisements802 a and 802 b may include, for example, the link local address of therouter device 206 a (e.g., fe80::acb2:12ff:fece:fe11 in the illustratedembodiment) as the source address, the ISP prefix for the ISP system 202a (e.g., 200::/64 in the illustrated embodiment), as well as a as wellas any other router advertisement information known in the art. Inaddition, the router advertisement engine 304 in the router device 206a/300 may set router lifetime information in the second routeradvertisements 802 a and 802 b to zero, and set the preferred lifetimeand valid lifetime associated with the address of the ISP system 202 ato zero. For example, the router advertisement engine 304 in the routerdevice 206 a/300 may set the router lifetime, the preferred lifetime,and the valid lifetime in the second router advertisements 802 a and 802b to zero. Furthermore, the second router advertisements 802 a and 802 bmay include a remaining lifetime of the address of the ISP system 202 a(e.g., the prefix 200::/64 in this embodiment) that the routeradvertisement engine 304 in the router device 206 a/300 sets to zero aswell. Each of the preferred, valid, and remaining lifetime may beassociated with the address of the ISP system 202 a (e.g., 200::/64 inthis embodiment) by providing the prefix for that address in the secondrouter advertisements 802 a and 802 b. The default router determinationengine 404 in each of the client devices 210 a/300 and 212 b/400 (aswell as any other client devices in the datacenter 214) may receive thesecond router advertisements through the communication system 408 atblock 506.

Referring now to FIG. 9, an embodiment of a router advertisement 900that may be second router advertisements 802 a and 802 b sent by therouter device 206 a discussed above with reference to FIG. 8 isillustrated. As can be seen the router advertisement 900 includes aplurality of fields such as a router lifetime field 901, a validlifetime field 902, a preferred lifetime field 904, a remaining lifetimefield 906, and a prefix field 908. In addition, one of skill in the artin possession of the present disclosure will recognize that the routeradvertisement may include the type, code, checksum, current hop limit,M|O, reachable time, retransmittal time, length, prefix length,reserved, and other router advertisement fields that are not providedwith element numbers in FIG. 9. As discussed above, lifetime informationin the router advertisement 900 may be set to zero by setting the routerlifetime field 901, the valid lifetime field 902, the preferred lifetimefield 904, and the remaining lifetime field 906 to zero, and thelifetime information that is set to zero may be associated with anaddress of an ISP system by providing a prefix for the address of theISP system (e.g., the ISP system 202 a in FIGS. 2, 6, 7, and 8) in theprefix field 908. While a specific embodiment of a router advertisementis illustrated, one of skill in the art in possession of the presentdisclosure will recognize that modifications to the router advertisement900 will fall within the scope of the present disclosure.

The method 500 then proceeds to decision block 508 where the clientdevices determine whether they have security enabled. In someembodiments, the client devices 210 a and/or 212 b may be configuredwith security such as, for example, according to the Secure NeighborDiscovery (SEND) protocol. As discussed below, with security enabled ina client device, that client device may immediately switchover theirtraffic to a different router device in response to receiving the secondrouter advertisement with the lifetime information set to zero asdiscussed above. However, if security is not enabled in a client device,that client device may need to confirm that the ISP system isunavailable before switchover of traffic in order to, for example,prevent the receipt of malicious router advertisements from resulting ina traffic switchover when an ISP system is available. If, at decisionblock 508, the default router determination engine 404 in the clientdevice 210 a/400 or 212 b/400 determines it has security enabled, themethod 500 may proceed immediately to block 518 where the client deviceselects a second router device that is coupled to a second ISP system asits default router device (as well as removes the address informationfor the unavailable ISP system from its databases to prevent the use ofthat address information with existing traffic flows that could causethose traffic flows to be dropped due to source address filtering by theavailable ISP system) and sends traffic to the second ISP system throughthe second router device (e.g., by providing address information for theavailable ISP system as a source address for that traffic), discussed infurther detail below. If, at decision block 508, the default routerdetermination engine 404 in the client device 210 a/400 or 212 b/400determines it does not have security enabled, the method 500 may proceedto decision block 510 where the client device determines whether it hasreceived an address confirmation request message.

In an embodiment of decision block 510, the default router determinationengine 404 in the client device 210 a/400 or 212 b/400 determineswhether it has received an address confirmation request message. In anembodiment, upon receiving the second router advertisements 802 a and802 b from the first router device 206 a that include the routerlifetime information set to zero, and lifetime information associatedwith the address of the ISP system 202 a set to zero, the default routerdetermination engine 404 in the client device 210 a/400 and 212 b/400may monitor a timer for some time period to determine whether an addressconfirmation request message is received. For example, upon receivingthe second router advertisements 802 a and 802 b from the first routerdevice 206 a that include the router lifetime information set to zero,and the remaining lifetime information associated with the address ofthe ISP system 202 a set to zero, the default router determinationengine 404 in the client device 210 a/400 and 212 b/400 may start atimer that is set to a random time period (e.g., between 0-1 seconds),monitor that timer, and determine whether an address confirmationrequest message is received during the time period. If, at decisionblock 510, it is determined that the client device has not received anaddress confirmation request message, the method 500 proceeds to block512 where that client device sends an address confirmation requestmessage that includes the address of the first ISP system (e.g., theprefix 200::/64 in this embodiment). If, at decision block 510, it isdetermined that the client device has received an address confirmationrequest message, the method 500 proceeds to decision block 514 wherethat client device determines whether an address confirmation replymessage has been received. In an embodiment, the router determinationengine 404 in a client device 400 that has received an addressconfirmation request message from another client device may set anaddress confirmation reply timer, discussed in further detail below, inresponse to receiving that address confirmation request message. One ofskill in the art in possession of the present disclosure will recognizethat block 510 prevents the flooding of the network with the addressconfirmation request messages discussed below by ensuring that only one(or only a few) client devices will send address confirmation requestmessage (e.g., due to the sending of the address confirmation requestmessage based on a randomly selected time period, and not sending theaddress confirmation request message if an address confirmation requestmessage is received during that randomly selected time period thatincludes the same prefix.)

In an embodiment, the method 500 proceeds to block 512 in response tothe default router determination engine 404 in the client device 210a/400 determining that it has not received an address confirmationrequest message (e.g., during some time period). Referring now to FIG.10, in an embodiment of block 512, the router determination engine 404in that client device 212 a/400 then sends address confirmation requestmessages 1000 a, 1000 b, and 1000 c throughout the datacenter 214 thatinclude the prefix of the ISP system 202 a (e.g., 200::/64 in thisembodiment). In an embodiment, the router determination engine 404 inthat client device 210 a/400 may also set an address confirmation replytimer, discussed in further detail below, in response to sending theaddress confirmation request messages 1000 a-c. As discussed above, thereceipt of the address confirmation request message 1000 c by the clientdevice 212 b before some time period after receiving the second routeradvertisement 802 from the router device 206 a will cause the routerdetermination engine 404 in that client device 212 b/400 to not send outan address confirmation request message (similar to the addressconfirmation request messages 1000 a-c) in order to, for example,prevent the flooding of the network with address confirmation requestmessages from each of the client devices in the datacenter 214 thatreceive the second router advertisement 802.

Referring now to FIG. 11, an embodiment of an address confirmationrequest message 1100 is illustrated that may be sent by a client deviceat block 512. In the illustrated embodiment, the address confirmationrequest message 1100 includes a type field 1102 and a target prefixfield 1104. In addition, one of skill in the art in possession of thepresent disclosure will recognize that the address confirmation requestmessage may include the code, checksum, target prefix length, and routerlifetime fields that are not provided with element numbers in FIG. 11.Type information may be provided in the type field 1102 that providessome newly defined value (e.g., reserved in the Internet Control MessageProtocol (ICMP)) for the address confirmation request message 1100. Inaddition, address information for the address of the ISP system that wasreceived in the router advertisement 802 from the router device 206 a(e.g., the prefix 200::/64 in this embodiment) may be provided in thetarget prefix field 1104. While a specific embodiment of an addressconfirmation request message is illustrated, one of skill in the art inpossession of the present disclosure will recognize that modificationsto the address confirmation request message 1100 will fall within thescope of the present disclosure.

In an embodiment, the address confirmation request messages discussedabove may be generated by a client device in response to receiving arouter advertisement with the router lifetime set to zero or less thanthe current remaining router lifetime stored on the client device for aparticular default router device. In such embodiments, the client devicemay receive the router advertisement with a target prefix of theassociated ISP system, the source link local address of the routerdevice, a prefix length of 128, and the router lifetime and, if thatrouter lifetime is greater than the router lifetime currently includedin the client device, the client device ignores the routeradvertisement, while if that router lifetime is zero or less than therouter lifetime currently included in the client device, the clientdevice may operate to send the address confirmation request message asdiscussed above.

Following the sending of the address confirmation request message atblock 512 (e.g., by the client device 206 a as discussed above), or inresponse to the determination at decision block 510 that an addressconfirmation request message has been received (e.g., by the clientdevice 206 b as discussed above), the method 500 proceeds to decisionblock 514 where the client device determines whether an addressconfirmation reply message has been received. In an embodiment, atdecision block 514, the default router determination engine 404 in theclient devices 210 a/300 and 212 b determines whether an addressconfirmation reply message has been received through the communicationsystem 408. In an embodiment, upon receiving the address confirmationrequest message 1000 a from the client device 212 b through itscommunication system 308, the router advertisement engine 304 in therouter device 300 references the address of the ISP system included inthe address confirmation request message 1000 a (e.g., the prefixinformation in the target prefix field 1104 discussed above withreference to FIG. 11) and determines whether that address informationmatches an invalid address information in the router device database(s)306. For example, as discussed above, if a dynamic routing update fromthe ISP system 202 a is not received within some time period, thedefault route associated with the prefix for that ISP system (e.g.,200::/64 in the illustrated embodiment) may be withdrawn by the routeradvertisement engine 304 in the router device 300 such that the prefixfor that ISP system is stored in the router device database(s) 306 as aninvalid prefix. At decision block 514, the router advertisement engine304 in the router device 300 may determine whether the prefixinformation in the target prefix field 1104 of the received addressconfirmation request message 1000 a matches an invalid prefix in therouter device database(s) 306. With reference to FIG. 12, if the addressinformation in the address confirmation request message 1000 a does notmatch an invalid address information in the router device database(s)306, the router advertisement engine 304 in the router device 300 willsend out address confirmation reply messages 1200 a and 1200 b to theclient devices 210 a and 212 b (as well as other client devices in thedatacenter 214). If the address information in the address confirmationrequest message 1000 a matches an invalid address information in therouter device database(s) 306, the router advertisement engine 304 inthe router device 300 will not send out an address confirmation replymessage. In an embodiment, a target prefix of the ISP system in theaddress confirmation request message may correspond to the link localaddress of the router device and may cause the router device to checkits current effective router lifetime (which will be zero if the ISPsystem is unavailable) and, if that value is not equal to the routerlifetime in the address confirmation request message, the router devicemay send an address confirmation reply message.

Referring now to FIG. 13, an embodiment of an address confirmation replymessage 1300 is illustrated that may be sent by a router device atdecision block 514. In the illustrated embodiment, the addressconfirmation reply message 1300 includes a type field 1302 and a targetprefix field 1304. In addition, one of skill in the art in possession ofthe present disclosure will recognize that the address confirmationrequest message may include the code, checksum, target prefix lengthfields that are not provided with element numbers in FIG. 13. Typeinformation may be provided in the type field 1302 that provides somenewly defined value (e.g., reserved in the Internet Control MessageProtocol (ICMP)) for the address confirmation reply message 1300. Inaddition, address information for the address of the ISP system that wasdetermined to be valid by the router device (e.g., the prefix 200::/64in this embodiment) may be provided in the target prefix field 1304.While a specific embodiment of an address confirmation reply message isillustrated, one of skill in the art in possession of the presentdisclosure will recognize that modifications to the address confirmationreply message 1300 will fall within the scope of the present disclosure.

In an embodiment of decision block 514, the router determination engine404 in the client device 210 a/400 and the client device 202 a/300determines whether an address confirmation request message has beenreceived within a time period (e.g., 3 seconds) that may be determinedby the address confirmation reply timer discussed above. If the clientdevice receives the address confirmation reply message at decision block514 (e.g., within some time period), the method 500 proceeds to block516 where the client device sends traffic to the first ISP systemthrough the first router device. In an embodiment, if the routerdetermination engine 404 in the client device 210 a/400 and the clientdevice 212 b/400 receive the respective address confirmation replymessage 1200 a and 1200 b and determine that they include the prefix forthe ISP system 202 a (e.g., 200::/64 in this embodiment), and the method500 proceeds to block 516 where router determination engine 404 in theclient device 210 a/400 and the client device 212 b/400 continues tosend their respective traffic 700, 702 to the ISP system 202 a throughthe router device 206 a, as illustrated in FIG. 7. Thus, decision block510, block 512, decision block 514, and block 516 may be performed bythe client devices 210 a and 212 b to check whether the ISP system 202 ais available through the router device 206 a in response to receiving anrouter advertisement that has set the lifetime information associatedwith the address of that ISP system 202 a to zero, which ensures thatmalicious router advertisements will not cause the switching of trafficto a different ISP system (as the router device 206 a will respond withan address confirmation reply message and prevent the switchover). Themethod 500 will then proceed back to block 506 and operate as discussedabove if the client devices 210 a and 212 b receive a routeradvertisement similar to the second router advertisement discussedabove.

If the client device receives the address confirmation request messageat decision block 514 (e.g., within some time period), or following thedetermination at decision block 508 that security is enabled in theclient device, the method 500 proceeds to block 518 where the clientdevice selects a second router device that is coupled to a second ISPsystem as its default router device and send traffic to the second ISPsystem through the second router device. In an embodiment, the routerdetermination engine 404 in the client device 210 a/400 and the clientdevice 212 b/400 select the second router device 206 b as their defaultrouter devices and send their respective traffic 700, 702 to the ISPsystem 202 b through the router device 206 b. Thus, in response toreceiving an router advertisement that has set the lifetime informationassociated with the address of the ISP system 202 a to zero, the clientdevices 210 a and 212 b will select a new default router device andbeing sending all of their traffic to a new ISP system through that newdefault router device.

In an embodiment, upon receiving a router advertisement, the clientdevices may determine whether the source address in that routeradvertisement (e.g., the link local address of the router device sendingthe router advertisement) matches an entry in a default router device inthe client device database 406 and, if so, that client device may startthe timer and send the address confirmation request message as discussedabove. In some embodiments, client devices may be configured to disablethe sending and/or receiving of address confirmation request messagesand address confirmation reply messages if the number of such messagesthat are sent for the same ISP system prefix exceeds a threshold in sometime period, and that ISP system prefix may be determined to be invalidin such situations that may arise due to a malicious attack on thedatacenter 214. Furthermore, the client device will ignore addressconfirmation request messages and address confirmation reply messages ifno address confirmation request timer or address confirmation replytimer has been started.

One of skill in the art in possession of the present disclosure willrecognize that the second router advertisement 802 that advertises therouter device 206 a as a non-default router device by setting the routerlifetime of the router device, and the preferred and valid lifetimeassociated with the address of the ISP system 202 a, to zero will causethe client devices to select a new default router device for any newtraffic flows generated or otherwise provided through that client devicefollowing the receipt of that second router advertisement 802.Additionally, the available ISP system may be selected by the clientdevice based on a policy defined in the client device and/or usingmulti-homing source address selection techniques known in the art.

However, existing traffic flows that are transmitted before receiving arouter advertisement from a default router device that includespreferred and valid lifetime associated with the address of itsrespective ISP system set to zero will continue to use the previoussource address of the unavailable ISP system due to standards (e.g., RFC4862) that protect from malicious router advertisements by setting thevalid lifetime of the default router device to an extended time period(e.g., 2 hours) that delays existing traffic switchover actions to 2hours subsequent to the router advertisement that sets the preferred andvalid lifetimes to zero. Use of that previous source address with thenewly selected default router device may cause traffic drops in theavailable ISP system if subjected to source address filtering due to theprevious source address of the unavailable ISP system being used withthe traffic being different than the address being provided by theavailable ISP system. The changing of a source address for the trafficis subject to that source address being determined to be invalid, andRFC 4862 sets the address valid lifetime to 2 hours upon receiving avalid lifetime set to zero, and thus the previous source address of theunavailable ISP system will still be valid for 2 hours upon receivingthe router advertisement. However, the systems and methods of thepresent disclosure remedy this issue by allowing the client devices toswitchover new and existing traffic flows to a newly selected defaultrouter device and declare the previous source address of the unavailableISP system as invalid immediately following the receipt of a routeradvertisement from a default router device that includes the routerlifetime set to zero, and the preferred, valid, and remaining lifetimesfor the address of its respective ISP system set to zero, all whileprotecting against malicious router advertisements as discussed above.

Thus, systems and methods have been described that provide for defaultrouter devices to detect unavailable links to their ISP systems and sendout router advertisements with router lifetime information for therouter device and lifetime information associated with the addressprefix of their unavailable ISP systems set to zero. The client deviceswill then select a new default router device through which to sendtraffic to its respective available ISP system. Furthermore, clientdevices without security enabled will perform such switchovers onlyafter ensuring that the switchover is not in response to maliciousrouter advertisements by soliciting a confirmation from the defaultrouter device in a manner that doesn't flood the network with traffic.As such, multi-homed networks are provided with redundant ISP systemsand may quickly switchover to the redundant ISP system in the event anISP system that is currently being used become available, which reducesthe loss of traffic due to the unavailability of an ISP system to amulti-homed network.

Although illustrative embodiments have been shown and described, a widerange of modification, change and substitution is contemplated in theforegoing disclosure and in some instances, some features of theembodiments may be employed without a corresponding use of otherfeatures. Accordingly, it is appropriate that the appended claims beconstrued broadly and in a manner consistent with the scope of theembodiments disclosed herein.

What is claimed is:
 1. A multi-homing Internet service providerswitchover system, comprising: a plurality of Internet service providersystems; a plurality of router devices, wherein a respective routerdevice of the plurality of router devices is coupled to each of theplurality of Internet service provider systems, and wherein each of theplurality of router devices is configured to: determine that a route toits respective Internet service provider system is unavailable and, inresponse, advertise as a non-default router device with router lifetimeinformation and lifetime information associated with an address of itsrespective Internet service provider system set to zero; and a clientdevice coupled to the plurality of router devices, wherein the clientdevice is configured to: receive a router advertisement from a firstrouter device of the plurality of router devices that is selected as adefault router device and that is coupled to a first Internet serviceprovider of the plurality of Internet service providers; and determinethat the router advertisement includes router lifetime information andlifetime information that is associated with the address of the firstInternet service provider system set to zero and, in response, select asecond router device of the plurality of router devices that isdifferent than the first router device as the default router device suchthat traffic that is being sent to the first Internet service providersystem through the first router device is sent to a second Internetservice provider system through the second router device.
 2. The systemof claim 1, wherein each of the plurality of router devices isconfigured to: determine that a route to its respective Internet serviceprovider system is available and, in response, advertise as a defaultrouter device.
 3. The system of claim 1, wherein the lifetimeinformation that is associated with the address of the first Internetservice provider system includes a preferred lifetime, a valid lifetime,and a remaining lifetime.
 4. The system of claim 1, wherein the clientdevice is configured to determine that the lifetime information that isassociated with the address of the first Internet service providersystem is set to zero and, in response, send an address confirmationrequest message that includes the address of the first Internet serviceprovider system.
 5. The system of claim 4, wherein the client device isconfigured determine that no address confirmation reply message has beenreceived within a time period following the sending of the addressconfirmation request message and, in response, select the second routerdevice as the default router device such that traffic that is being sentto the first Internet service provider system through the first routerdevice is sent to the second Internet service provider system throughthe second router device.
 6. The system of claim 4, wherein the firstrouter device is configured to receive the address confirmation request,determine whether the first Internet service provider system isavailable and, in response to determining that the first Internetservice provider system is available, send an address confirmation replymessage that indicates the address of the first Internet serviceprovider system is valid.
 7. An information handling system (IHS),comprising: a communication system that is configured to couple to aplurality of router devices that are each coupled to a respectiveInternet service provider system; a processing system that is coupled tothe communication system; and a memory system that is coupled to theprocessing system and that includes instructions that, when executed bythe processing system, cause the processing system to provide a defaultrouter determination engine that is configured to: send, through thecommunication system, traffic to a first Internet service providersystem through to a first router device of the plurality of routerdevices that is selected as a default router device; and receive,through the communication system from the first router device, a secondrouter advertisement that includes router lifetime information andlifetime information associated with an address of the first Internetservice provider system set to zero and, in response, select a secondrouter device of the plurality of router devices that is different thanthe first router device as the default router device such that thetraffic is sent to a second Internet service provider system through thesecond router device.
 8. The IHS of claim 7, wherein the default routerdetermination engine is configured to: receive, through thecommunication system from the first router device, a first routeradvertisement that is sent prior to the second router advertisement andthat advertises the first router device as a default router device and,in response, select the first router device as the default router deviceand send the traffic to the first Internet service provider systemthrough the first router device.
 9. The IHS of claim 7, wherein thelifetime information associated with the address of the first Internetservice provider system includes a preferred lifetime, a valid lifetime,and a remaining lifetime.
 10. The IHS of claim 7, wherein the defaultrouter determination engine is configured to: determine that thelifetime information associated with the address of the first Internetservice provider system is set to zero and, in response, send an addressconfirmation request message that includes the address of the firstInternet service provider system.
 11. The IHS of claim 10, wherein thedefault router determination engine is configured to: determine that noaddress confirmation reply message has been received within a timeperiod following the sending of the address confirmation request messageand, in response, select the second router device as the default routerdevice such that traffic that is being sent to the first Internetservice provider system through the first router device is sent to thesecond Internet service provider system through the second routerdevice.
 12. The IHS of claim 10, wherein the default routerdetermination engine is configured to: determine that the lifetimeinformation associated with the address of the first Internet serviceprovider system is set to zero and, in response, send the addressconfirmation request message that includes the address of the firstInternet service provider system in response to determining that noother address confirmation request messages have been received within atime period.
 13. The IHS of claim 7, wherein the default routerdetermination engine is configured to: determine that an addressconfirmation reply message that indicates the address of the firstInternet service provider system is valid has been received within atime period following the sending of the address confirmation requestmessage and, in response, continue to send the traffic to the firstInternet service provider system through the first router device.
 14. Amethod for Internet service provider switchover in a multi-homingsystem, comprising: sending, by a client device, traffic to a firstInternet service provider system through to a first router device thatis selected as a default router device; receiving, by the client devicefrom the first router device, a second router advertisement thatincludes router lifetime information and lifetime information associatedwith an address of the first Internet service provider system set tozero; and selecting, by the client device in response to receiving thesecond router advertisement that includes the router lifetimeinformation and the lifetime information associated with the address ofthe first Internet service provider system set to zero, a second routerdevice that is different than the first router device as the defaultrouter device such that the traffic is sent to a second Internet serviceprovider system through the second router device.
 15. The method ofclaim 14, further comprising: receive, by the client device from thefirst router device, a first router advertisement that is sent prior tothe second router advertisement and that advertises the first routerdevice as a default router device and, in response, selecting the firstrouter device as the default router device and sending the traffic tothe first Internet service provider system through the first routerdevice.
 16. The method of claim 14, wherein the lifetime informationassociated with the address of the first Internet service providersystem includes a preferred lifetime, a valid lifetime, and a remaininglifetime.
 17. The method of claim 14, further comprising: determining,by the client device, that the lifetime information associated with theaddress of the first Internet service provider system is set to zeroand, in response, sending an address confirmation request message thatincludes the address of the first Internet service provider system. 18.The method of claim 17, further comprising: determining, by the clientdevice, that no address confirmation reply message has been receivedwithin a time period following the sending of the address confirmationrequest message and, in response, selecting the second router device asthe default router device such that traffic that is being sent to thefirst Internet service provider system through the first router deviceis sent to the second Internet service provider system through thesecond router device.
 19. The method of claim 17, further comprising:determining, by the client device, that the lifetime informationassociated with the address of the first Internet service providersystem is set to zero and, in response, sending the address confirmationrequest message that includes the address of the first Internet serviceprovider system in response to determining that no other addressconfirmation request messages have been received within a time period.20. The method of claim 14, further comprising: determining, by theclient device, that an address confirmation reply message that indicatesthe address of the first Internet service provider system is valid hasbeen received within a time period following the sending of the addressconfirmation request message and, in response, continuing to send thetraffic to the first Internet service provider system through the firstrouter device.